In the study item UTRAN long term evolution (LTE) initiated by the 3rd Generation Partnership program (3GPP) it has been decided that a scheduling mechanism similar to the one used in Enhanced D-Channel Handler (E-DCH) shall be adopted for LTE. The scheduler in a Node B schedules resources in both downlink and uplink. In the uplink, the scheduler needs information about the data that is available in the buffers of the user equipments (UE). This is achieved by transmitting scheduling information messages from the user equipment to the Node B. The scheduling information is transmitted as part of the Medium Access Layer Protocol (MAC) and can therefore be either piggybacked with other transmissions (when those are ongoing) or be sent stand alone by creating MAC PDUs just to transfer the scheduling information. The scheduling information in E-DCH has the format depicted in FIG. 1. HLID denotes the Highest priority Logical channel ID; TEBS denotes the Total E-DCH Buffer Status; HLBS denotes the Highest priority Logical channel Buffer Status (which is a value that is coded relative to TEBS, i.e. a percent of indicated TEBS value); and UPH denotes the UE Power Headroom (which field relates to the power used in the UE). When the scheduling information is received in the Node B, the scheduler can determine the logical channel that has the highest priority (HLID), how much data that is stored in the UE buffer for this logical channel (HLBS), and the total UE buffer size (TEBS). In total this information is encoded in 13 bits.
In a long-term evolution (LTE-) system there is a desire to employ a finer granularity on the QoS than is possible in E-DCH. The E-DCH solution has some limitations. If the user equipment has data on several logical channels (radio bearers) it is only possible to see the amount of data on the channel with the highest priority. It is, however, not possible to know if the remaining data has rather high, low, or very low priority. It is neither possible to know how the data is distributed between these priorities. This means that it is difficult to achieve service differentiation for any other service than the one with highest priority.
A prior-art solution to this problem is to signal the buffer status per radio bearer (or per priority/QoS class). In order to achieve a reasonable low size of the buffer status message the number of bits for the buffer size of each radio bearer (or priority/QoS class) needs to be rather low, e.g. 2 bits per buffer as will be used in the following. This solution, however, implies the disadvantage that it provides a very poor granularity when in comes to the total buffer size of the user equipment. When assuming, for example, that there is only data available for one radio bearer the total UE buffer is then encoded with only 2 bits, which is not sufficient. Clearly the number of bits per buffer can be increased but that leads to a large buffer status message. One conceivable option could be to encode the total buffer size separately. In that way relatively few bits could be used to encode the buffer size for each radio bearer (e.g. 2 bits) and an additional N bits could be used to encode the total buffer size. This would result in both a rough view of the buffer size per radio bearer as well as a reasonable accurate indication of the total buffer size. However, this would also lead to a large total buffer status message.
Other reasons of having a finer granularity than in the E-DCH scheduling solution, include among others:    1) Starvation between QoS levels within a single UE: Low priority data flows may be starved by higher priority traffic    2) Inability for the operator to control cell capacity partitioning between QoS classes: Scheduler can in E-DCH not know which radio bearers that have data (except for the highest priority radio bearer which is indicated explicitly)    3) Low-priority traffic hitching a free ride: Low priority data may get a free ride when high priority data is scheduled if the scheduler is not aware how much data that is available on different radio bearers